From: Neil Wagoner (1/24/96) To: infosec@smiley.mitre.org Mail*Link¨ SMTP Microsoft's CAPI Received: by iegate.mitre.org with SMTP;24 Jan 1996 08:01:14 -0500 Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by mbunix.mitre.org (8.6.10/8.6.9) with ESMTP id HAA18448 for ; Wed, 24 Jan 1996 07:56:58 -0500 Received: (root@localhost) by mwunix.mitre.org (8.6.10/8.6.4) id HAA12268 for fnc@mbunix.mitre.org; Wed, 24 Jan 1996 07:56:57 -0500 Received: from smiley.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id HAA11945; Wed, 24 Jan 1996 07:56:40 -0500 Received: from [128.29.140.170] (m24975-pc) by smiley.sit (4.1/SMI-4.1) id AA24337; Wed, 24 Jan 96 07:56:07 EST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jan 1996 08:01:23 -0500 To: infosec@smiley.mitre.org From: nwagoner@smiley.mitre.org (Neil Wagoner) Subject: Microsoft's CAPI X-MDF: Mail for fnc sent to fnc@mbunix.mitre.org FYI: >From: JIM_SCHINDLER@HP6650.desk.hp.com >X-Openmail-Hops: 2 >Date: Tue, 23 Jan 96 15:23:00 -0700 >Subject: Microsoft's CAPI >Sender: JIM_SCHINDLER%HP6650.desk.hp.com@CUP.HP.COM >To: sig-security@OSF.org >X-Mdf: Mail for nwagoner sent to nwagoner@smiley.mitre.org > > > Date: Wed, 17 Jan 1996 10:02:27 -0500 > From: Matt Blaze > > I attended a meeting at Microsoft the other day at which they > described their Crypto API project. As CAPIs go, it's reasonable > enough; nothing particularly exciting about it or especially wrong > with it (though they don't yet support nonblocking calls to crypto > modules). > > They've defined 23 cryptographic services (establish key, encrypt, > etc.) that an application is expected to use for its cryptographic > needs. The idea is to hide the crypto details (and keys) from > applications, and to make it easy to switch from, say, wimpy > export-approved crypto to good crypto just by switching to another DLL > at load-time. The cryptography used depends on the crypto modules in > use at runtime. The API will be part of the WIN32 interface. The > next version of NT (and windows 95, I think), to be released in a few > months will support loading ``Cryptographic Service Providers'' (CSPs) > that contain the crypto functions that sit below the API. They have > (or will have soon) an application development kit to allow you to > write code that uses the API, and a CSP development kit to let you > write the crypto functions. > > The interesting part is that they say they've made a deal with the > government to allow applications that use the API to be exportable as > long as they don't also try to implement crypto on their own. > Ordinarily, the government claims that ``crypto with a hole'' > (applications that call a crypto API) are just as export-controlled as > crypto functions themselves, so this is something of a surprise and > would represent considerable forward progress. But, of course, > there's a catch. > > The OS will not load just any old CSP. CSPs have to be signed by > Microsoft. The kernel contains a (hardcoded?) 1024 RSA public key > that it uses to check the signature when the user tries to load a CSP. > If the signature check fails, the CSP won't load. Microsoft says it > will sign any CSP from anyone AS LONG AS THEY CERTIFY THAT THEY WILL > FOLLOW THE EXPORT RULES. So you can get your CSP signed if you use > exportable cryptography or if you agree not to send it outside the US > and Canada, etc. But an end user can't just compile crypto code and > use it as a CSP, even for his or her own use, without getting it > signed by Microsoft first (actually, the CSP development kit does > allow this, but it uses a special version of the OS). > > I'm not sure whether this whole thing is good or bad. One important > issue is whether MS will really sign anyone's CSP or whether they will > start charging high fees or making business-based decisions on who's > CSPs they will allow (with they sign Netscape's CSP, for example). > They say they won't even look or keep a copy of your CSP (at my > suggestion, they are probably going to change the process so that you > send them a hash of your CSP instead of your CSP code when you get the > signature). For now they promise to sign CSPs for anyone who returns > the export certificate, at no charge. > > We (Jack Lacy and I) will probably implement, get signed, and give > away a CryptoLib-based CSP (not for export) for which we will also > make source available so people examine the source to their crypto > (most CSPs will, presumably, not include source). > > Despite all this, I think it will be easy to get around the CSP > signature requirements and use homebrew, unsigned crypto even with > pre-compiled .exe files from other sources. I suspect it will be easy > to write a program, for example, that takes an executable program > and converts CryptoAPI calls to calls that look like just another DLL. > And I'm sure someone will write a program to patch the NT/Windows > kernel to ignore the signature check. Needless to say, it would be > nice if someone outside the US were to write and distribute programs > to do this. It would also be nice if someone would write a Unix/Linux > version of the API/CSP mechanism. It might make it possible to export > applications for those platforms as well. > > I haven't tried any of this out yet, but they say they will have beta > versions of the API and CSP developers kits out in a few weeks. They > say that the API kit will not be export-controlled but the CSP kit > will be. They plan to announce all this at the RSA conference this > week. > > -matt ======================================================================